Many business applications have been developed to meet the various needs of organizations, such as companies, nonprofit organizations, and governmental agencies. These business applications may include customer relationship management (“CRM”) applications, inventory management applications, human resource applications, accounting applications, payroll applications, project management applications, and so on. Since a single business application is unlikely to meet all the information processing needs of an organization, organizations typically use several different business applications to meet their needs.
Each business application needs to access data of the organization to perform its processing. Data of an organization is typically stored on a per-entity basis. An entity may be a person, a group of people (e.g., a marketing group), a company, a piece of equipment, an order, and so on. Each business application may maintain its own copy of the data for an entity and may actually maintain data for an entity that is different from data maintained by other business applications for that entity. For example, a human resources application may maintain detailed data about each employee of the organization including employee identification number, social security number, age, home address, tax information (e.g., marital status), technical skills (e.g., welder), grade level (e.g., apprentice), and so on. A project management application, in contrast, may need to store for each employee only a subset of that data that includes employee identification number, technical skills, and grade level. Each entity typically has a unique identifier (e.g., employee number or customer number) that never changes. In this way, the entity can be uniquely identified even though its name or other attributes change.
It might be desirable for an organization to store its data for all its entities in a central database that is accessed by each business application as needed. Unfortunately, the use of such a central database is impractical for several reasons. First, most existing business applications have been developed to maintain their own copy of the data that they need. Even if all the different developers were to agree upon a standard for accessing data of a central database, it would be very time-consuming and costly to modify each business application to access a central database. Second, some business applications may have certain time constraints for accessing data that cannot be satisfied when a central database is used. For example, a banking application may need to access and update account information within a fraction of a second of receiving deposit requests, withdrawal requests, balance requests, and so on from automated teller machines (“ATMs”). The overhead of a central database may not allow for such timely access.
Since many business applications maintain their own copy of data of an entity, there is a possibility that an update to one copy of the data of an entity will not be promulgated to other copies of that data. Thus, the different copies of the data will not be synchronized, and it will be difficult to determine what actually is the correct data for an entity. To keep its data synchronized, an organization may develop ad hoc programs for each pair of business applications that check for and replicate updates to data. The developing of such ad hoc programs for each pair of business application is expensive, time-consuming, and error-prone.